Vorhersage (Klassifikation) betrügerischer Kontotransationen

Solution Engineering in R

Daniel Borsos, Valerie Högerle, Michaela Hubweber, Florian Ye

2024-05-07

Milestone 1

Motivation

Betrug und andere Wirtschaftsdelikte sind weitverbreitet: In der PwC’s Global Economic Crime and Fraud Survey 2022 waren 46% der Organisationen betroffen mit Schäden von vielen Millionen Euro. Dabei sind nicht nur Banken und Finanzsektor betroffen, sondern auch Branchen wie Einzelhandel bis Versicherungen und Gesundheit. Gleichzeit bietet die Vielzahl und Menge an Daten genau den Vorteil (z.B.: 2,3 Milliarden Visa und Mastercards in 2021) für Machine Learning, welches Fraud Detection in unterschiedlichen Branchen schnell, effizient und in großem Umfang ermöglichen kann. Quelle: https://www.teradata.com/insights/ai-and-machine-learning/fraud-detection-machine-learning

Zielsetzung des Projekts (qualitativ und quantitative Ziele)

Qualitative Ziele:

  • Entwicklung eines robusten Klassifikationsmodells: Entwickeln eines Modells, das effektiv zwischen betrügerischen und legitimen Transaktionen unterscheiden kann, unter besonderer Berücksichtigung des stark inbalanced Datensatzes.
  • Erkennung von Mustern und Anomalien: Identifizierung spezifischer Muster oder Anomalien in den Daten, die auf betrügerische Aktivitäten hindeuten könnten.
  • Nutzbarkeit und Zugänglichkeit: Erstellung einer benutzerfreundlichen Shiny-Anwendung, die es Endnutzern ermöglicht, Vorhersagen einfach zu generieren und die Ergebnisse intuitiv zu verstehen.

Quantitative Ziele:

  • ROC AUC-Wert: Erzielen eines ROC AUC-Wertes von mindestens 0.90, was auf eine ausgezeichnete Trennfähigkeit des Modells zwischen betrügerischen und legitimen Transaktionen hinweist.
  • Hoher Recall für betrügerische Transaktionen: Streben nach einem Recall-Wert von über 90% bei betrügerischen Transaktionen, um sicherzustellen, dass die meisten tatsächlichen Betrugsfälle korrekt erkannt werden. Dies ist besonders wichtig, da das Übersehen von Betrug schwerwiegendere Konsequenzen haben kann als falsche Alarme.
  • Ausgeglichener F1-Score für betrügerische Transaktionen: Ziel ist ein F1-Score von über 85% für die Klasse der betrügerischen Transaktionen, was ein gutes Gleichgewicht zwischen Präzision und Recall darstellt, wobei der Schwerpunkt auf dem Recall liegt.
  • Schnelle Antwortzeiten der Shiny-Anwendung: Die Shiny-Anwendung sollte in der Lage sein, innerhalb weniger Sekunden Vorhersagen zu liefern, um effektive Echtzeitanwendungen zu ermöglichen.

Beschreibung der Datengrundlage (Refenzdatensatz)

Die Grundlage des Kaggle-Datensatzes “Fraudulent Transactions Prediction” besteht aus Transaktionsdaten, die für die Erkennung von Betrug im Online-Zahlungsverkehr verwendet werden. Der Datensatz enthält verschiedene Attribute wie “step”, “type”, “amount”, “oldbalanceOrg”, “newbalanceOrig”, “nameDest”, “oldbalanceDest”, “newbalanceDest”, “isFraud” und “isFlaggedFraud”. Allerdings sind die Balance-Daten (“oldbalanceOrg”, “newbalanceOrig”, “oldbalanceDest”, “newbalanceDest”) nicht immer vollständig, da viele dieser Werte 0 sind.

Die Zielvariable “isFraud” ist außerdem unbalanciert, da 99.87% der Transaktionen nicht betrügerisch sind. Zudem scheint es keine signifikanten Korrelationen zwischen den Variablen zu geben, mit Ausnahme der Balance-Variablen, die viele Null-Werte enthalten und damit korrelieren .

Die Attribute im Überblick:

step: Zeiteinheit, wobei ein Schritt einer Stunde entspricht. type: Art der Online-Transaktion, z. B. “CASH_OUT”, “PAYMENT”, “CASH_IN”, “TRANSFER” oder “DEBIT”. amount: Betrag der Transaktion. nameOrig: ID des Ursprungs-Kontos. oldbalanceOrg: Anfangsguthaben des Ursprungs-Kontos. newbalanceOrig: Guthaben des Ursprungs-Kontos nach der Transaktion. nameDest: ID des Ziel-Kontos. oldbalanceDest: Anfangsguthaben des Ziel-Kontos. newbalanceDest: Guthaben des Ziel-Kontos nach der Transaktion. isFraud: Kennzeichnet, ob es sich um einen Betrugsfall handelt oder nicht. isFlaggedFraud: Kennzeichnet, ob die Transaktion als möglicher Betrugsfall markiert wurde.

Projektorganisation und Aufgabenteilung

Wir haben eine reine/autonome Projektorganisation, d.h. das Team arbeitet ausschließlich für die o.g. Ziele. Synergien könnten sich aus dem Python-Projekt mit identischer Gruppe ergeben, wobei die Organisation getrennt stattfindet. Da das Projekt ausreichend überschaubar ist, wird auf eine starke Struktur im Projektteam verzichte: z.B. gibt es keinen (ausschließlichen organisatorisch tätigen) Projektleiter, sondern alle vier Mitglieder sind hierarchisch gleichgestellt. Umso wichtiger werden Aufgabenteilung und Verantwortungen in Teilbereichen, die entsprechend der Stärken der Mitglieder verteilt werden. Die Erstellung und (hauptverantwortliche) Verwaltung in Github wurde von MH übernommen. Für die finalen Abgaben der (Zwischen-)Präsentationen ist VH verantwortlich. Die Aufgabenzuweisung und -organisation erfolgt über Github, kurzfristige Kommunikation und Absprachen erfolgen über eine zu Beginn des Projekts gegründete Chatgruppe. Ein Kick-Off-Meeting fand am 28.04.2024 statt, wo dieses Vorgehen besprochen wurde.

Es ergeben sich durch Vorgaben der Lehrveranstaltung vier Milestones, die sich z.B. im Kanban widerspiegeln und detaillierter im nächsten Kapitel aufgezeigt werden. Milestone 1/4 (R3): Projektpräsentation am 07.05.2024 Milestone 2/4 (R5): Zwischenpräsentation am 21.05.2024 Milestone 3/4: (R7) Projektabschlussbericht am 04.06.2024 Milestone 4/4: (R7) Abschlusspräsentation 04.06.2024

Das Projekt arbeitet agil, in zweiwöchigen Sprints entsprechend der Milestones (wobei Milestone 3+4 im selben Sprint R7 erreicht werden müssen). Die Aufgaben von R3 wurden am 30.04. verteilt, für R5 liegt die Planung seit dem 07.05. vor. Das Sprint Planning für den letzten Sprint wird für den 21.05. geplant und dort werden die letzten Aufgaben verteilt, um die Arbeit gleichmäßig und nach den Stärken der Einzelnen je nach konkretem Vorgehen zuzuteilen. Die Anforderungen, Rückfragen und ToDos der einzelnen Aufgaben sind ebenso wie die Verantwortlichen in GitHub im Project @FraudDetectionProject vermerkt und werden von VH gepflegt. Start- und Enddaten sind ebenfalls dort, falls bereits möglich, hinterlegt - auch wenn diese in der Projektübersicht innerhalb des Sprints und (noch) nicht mit individuellem Start- und Enddatum angezeigt werden.

Plan für die Ausarbeitung des Projekts (Workflow), Backlog

Projektplan und Workflow

Der Backlog des Projekts befindet sich im zugehörigen Repository und enthält die unten aufgeführten Aufgaben:

Backlog

Timetable
  1. Datenexploration und -vorbereitung
    • Datenimport und -exploration
    • Behandlung von fehlenden oder doppelten Werten
    • Feature Engineering und Transformation
  2. Modellentwicklung
    • Aufteilung der Daten in Trainings- und Testdaten
      • Behandlung des Klassenungleichgewichts durch Sampling?
    • Anwendung verschiedener Klassifikationsalgorithmen
      • Behandlung des Klassenungleichgewichts durch Wahl geeigneter Verfahren, die mit unbalancierten Daten umgehen können und/oder Gewichtung erlauben
    • Hyperparameter-Optimierung und Modellbewertung
  3. Modellvalidierung und -interpretation
    • Evaluation der Modelle anhand der festgelegten quantitativen Ziele, z.B. ROC AUC, Recall, F1-Score
      • Behandlung des Klassenungleichgewichts durch Wahl geeigneter Metriken
    • Interpretation der Modellergebnisse und Identifikation/Interpretation wichtiger Features
  4. Entwicklung der Shiny-Anwendung:
    • Implementierung einer benutzerfreundlichen Shiny-Anwendung
    • Integration des entwickelten Modells zur Generierung von Vorhersagen
    • Optimierung der Antwortzeiten für Echtzeitanwendungen
  5. Dokumentation und Präsentation
    • Erstellung von Dokumentationen und Präsentationen
    • Vorbereitung für die Abschlusspräsentation und -abgabe

Fragen? Anmerkungen? Diskussion?